Section: New Results

Secure Interpreters for Sessions

Participants : James Leifer, Jean Pichon [intern from ENST Telecom ParisTech] .

We developed an interpreter for decentralised multi-party sessions. The interpreter takes a graph-based description of a session and provides a high-level interface for sending and receiving messages permissible in the session. The interpreter protects the integrity of session execution in a realistic security setting where an adversary has the ability to: (1) control the network to capture and reinject messages at will, and read and forge messages using leaked cryptographic keys; (2) compromise arbitrary session participants. By producing and verifying cryptographic signatures, the interpreter ensures that all non-compromised participants have consistent views of the session’s execution history.

We previously worked on a session compiler. The compiler took as input “local graphs” described in process-calculus fashion. It produced one F# library for each role, and an F7 interface/specification for this library. If the library typechecked (with the F7 type-checker) against its interface, then it was secure. However, the production of the library was not itself verified, and could fail.

By contrast, this present work is concerned with a session interpreter. This interpreter works like an ML functor (i.e. a compile-time function from modules to modules). It takes as input a module describing a global graph by exposing a specific interface. The application of the interpreter functor to a graph module yields an F$☆$ module that contains the interface/specification. The interpreter functor, being checked against an abstract description of a graph, is typechecked “once and for all”. Because the interpreter functor typechecks against its interface (that contains specifications), it is secure (through refinements). The interpreter functor can then be applied to a concrete session graph to be used.

The interpreter is written in F$☆$, a dialect of ML enriched with refinement types, and its correctness is proven by type annotations.

The interpreter consists of approximately 3000 lines of code.